Fix resolved (template) values in case of failure #4532
Conversation
When the value cannot be resolved usually the original value is returned. However if it contains `%` signs there will be an escape step and that escaped value is returned. That makes it impossible to have values which can only later be resolved, like `cd %(startdir)s` in extensions which would become `cd %%(startdir)s` on the first resolve-attempt.
Flamefire
force-pushed
the
fix_partial_template_resolve
branch
from
30046af to
7323bae
Compare
|
@Flamefire The case from easybuilders/easybuild-easyconfigs#20119 that happens to work now should also be taken into account. |
I'm not sure we can and don't think we should. #4516 might also have avoided the issue we had as it avoids resolving where we can and allows failures at places where they might happen. Haven't checked but I guess there it won't try to resolve the extension values when reading them. And with this change it won't matter anymore how often EB tries to resolve templates until it succeeds: The value stays unchanged. Additionally we have: According to this no-one should expect that workaround to work, should they? And the idea was explicitly that things like |
When the value cannot be resolved usually the original value is returned.
However if it contains
%signs there will be an escape step and that escaped value is returned.That makes it impossible to have values which can only later be resolved, like
cd %(startdir)sin extensions which would becomecd %%(startdir)son the first resolve-attempt.This is impossible to "undo" in the current framework hence we must take care of this case.
I also did some related changes:
dict.itemsshould be usedresolve_templatewas not testedRecent actual failure was using
cp %s %(builddir)s/archivesas the extract command in a component. I'd argue that should work as expected although there is a workaround: Escaping the%(builddir)stemplate. But that kind of requires to know how many times EasyBuild will try to resolve templates.